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FOREWORD 

Among  the  responsibilities  assigned  to  the  Office  of  the  Manager,  National 
Communications  System,  is  the  management  of  the  Federal  Telecommunication 
Standards  Program.  Under  this  program,  the  NCS,  with  the  assistance  of  the 
Federal  Telecommunication  Standards  Committee  identified,  develops,  and 
coordinates  proposed  Federal  Standards  which  either  contribute  to  the 
interoperability  of  functionally  similar  Federal  telecommunication  systems  or 
to  the  achievement  of  a  compatible  and  efficient  interface  between  computer  and 
telecommunication  systems.  In  developing  and  coordinating  these  standards,  a 
considerable  amount  of  effort  is  expended  in  initiating  and  pursuing  joint 
standards  development  efforts  with  appropriate  technical  committees  of  the 
International  Organization  for  Standardization,  and  the  International  Telegraph 
and  Telephone  Consultative  Committee  of  the  International  Telecommunication 
Union.  This  Technical  Information  Bulletin  presents  and  overview  of  an  effort 
which  is  contributing  to  the  development  of  compatible  Federal,  national,  and 
international  standards  in  the  area  of  facsimile.  It  has  been  prepared  to 
inform  interested  Federal  activities  of  the  progress  of  these  efforts.  Any 
comments,  inputs  or  statements  of  requirements  which  could  assist  in  the 
advancement  of  this  work  are  welcome  and  should  be  addressed  to: 
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1.0  INTRODUCTION 


This  document  summarizes  work  performed  by  Delta  Information  Systems,  Inc. ,  for  the 
OflSce  of  Technology  and  Standards  of  the  National  Communications  System,  an  organization 
of  the  U.S.  Government,  under  Task  2  of  contract  number  DCA100-91-C-0031.  The  purpose 
of  this  task  is  to  modify  the  Group  4  Validation  System  to  align  it  with  revised  CCITT 
Recommendations  pertaining  to  Group  4  facsimile  equipment. 

Section  2.0,  "Group  4  Validation  System  Overview,"  provides  a  general  description  of 
the  Group  4  Validation  System.  The  description  outlines  the  software  and  hardware  design  taken 
to  satisfy  the  CCITT  Recommendations  governing  the  Group  4  facsimile  telematic  protocol 
structure. 

Section  3.0,  "Validation  System  Design,"  discusses  the  system  design  in  detail.  It 
reviews  the  hardware  and  software  design  approaches  for  implementing  the  telematic  protocol 
structure. 

Section  4.0,  "CCITT  Group  4  Recommendations  Revisions,"  discusses  the  revisions  to 
CCITT  Kecomrnendaiions  pcrutiniug  to  Group  4  facsimile  equipments. 

Section  5.0,  "Summary  and  Areas  of  Future  Study,"  summarizes  modifications  to  the 
Group  4  Validation  System  and  suggests  future  areas  of  modification. 


1.1  Group  4  Background  Information 

Group  4  is  the  latest  set  of  CCITT  facsimile  Recommendations,  and  was  primarily 
designed  for  operation  on  digital,  error-free,  high-speed  networks  such  as  public  data  networks. 


packet-switched  networks,  and  the  ISDN.  Moreover,  there  are  three  types  of  Group  4 
equipments  with  characteristics  as  shown  in  Table  1-1: 


Class  1 :  A  terminal  able  to  send  and  receive  facsimile  documents. 

Class  2:  A  terminal,  in  addition  to  having  Class  1  capabilities,  able 
to  receive  teletext  and  mixed-mode'  documents. 

Class  3:  A  terminal,  in  addition  to  having  Class  1  and  Class  2 
capabilities,  able  to  generate  and  send  teletext  and  mixed¬ 
mode  documents. 


Table  1-1.  Group  4  Class  Characteristics 


1 

Class 

2 

3 

Pel-density  of 
scanner-printer 
(pel8/25 ,4mm) 

200 

300 

300 

Pel  transmission 
density  (peU/25.4mm) 

200 

200/300 

200/300 

Pel  transmission 
conversion  capability 

not 

required 

required 

required 

Mixed-irodr  capability 

not 

required 

not 

required 

required 

Optional  pel  density 
of  scanner-printer 

300/400 

400 

400 

Combined  with 

pel  transmission  density 

(pel/25. 4mm) 

200/300/400 

200/300/400 

200/300/400 

Storage 

not 

required 

not 

required 

required 

Mixed-mode  ducumeots  contain  a  mixture  of  teletext  and  factimile  data  on  the  aame  page,  hor  example,  a  page  cooaiating  of  line  art  and  text 
could  be  lent  at  a  mixed-mode  document;  the  line  art  could  be  aent  aa  facatmile  data,  and  the  text  could  be  aeot  aa  teletext  data. 
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These  three  classes  provide  a  wide  range  of  capability.  For  example,  Group  4  Class  1 
is  similar  to  Group  3  (low  capability),  while  Classes  2  and  3  permit  interoperation  with  Teletex 
and  ..'>.ed-mode  equipments  (higher  capability).  Nevertheless,  being  Group  4  compliant  does 
not  mean  different  classes  of  Group  4  equipments  can  interoperate.  For  instance,  a  careful 
examination  of  Group  4’s  communication  protocols  (See  Figure  1-1)  reveals  slight  differences 
which  prevent  communications  between  Class  1  and  Class  3  equipments  (T.521  versus  T.522, 
etc.). 
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Figure  1-1.  Hierarchy  of  CCITT  Recommendations  for  Group  4  Facsimile 
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1.1.1  Communication  Protocol 


The  development  of  the  protocol  structure  for  Group  4  has  followed  a  rather  rocky  road 
and  as  a  result  its  protocol  and  classes  were  fractured  into  two  camps.  One  (Group  4  Class  1) 
uses  a  protocol  designed  specifically  for  Group  4  facsimile,  while  the  other  (Group  4  Classes 
2  and  3)  uses  a  protocol  designed  to  connect  to  many  different  types  of  systems  and  equipments 
(computer  systems,  facsimile  equipments,  etc.).  This  fracture  occurred  for  two  main  reasons: 
1)  the  CCITT’s  Document  Architecture  Recommendations  (DTAM),  upon  which  Croup  4 
depends,  were  published  prematurely  (Recommendation  T.73),  and  2)  the  protocol  for  Group 
4  Class  1  equipments  was  not  made  identical  to  the  protocol  for  Group  4  Classes  2  and  3  when 
DTAM  was  later  revised.  The  premature  publishing  of  the  DTAM  Recommendations  allowed 
several  manufacturers  to  build  Group  4  equipments  (especially  Class  1)  with  the  underlying 
assumption  that  the  CCITT  Group  4  Recommendations,  of  which  DTAM  is  a  part,  were  stable. 
Unfortunately,  this  was  not  true.  At  this  same  time,  the  CCITT  was  considering  incorporating 
into  Group  4  the  concepts  embodied  by  the  International  Organization  for  Standardization’s  (ISO) 
Open  Systems  Interconnection  (OSI)  standard  OSI  is  designed  to  permit  many  different  types 
of  systems  to  communicate  with  one  another  (especially  computer  systems),  and  is  not  tailored 
towards  any  particular  equipment  or  system.'"*^’  The  CCITT  decided  to  make  Group  4  OSI 
compliant,  and  as  a  result  revised  DTAM  (now  Recommendations  T.43 1-433).  This  created  a 
dilemma.  The  equipments  made  according  to  the  original  Recommendations  (T.73,  etc.)  would 
no  longer  be  Group  4  compliant.  So,  the  manufacturers  who  had  already  made  these  equipments 
requested  that  Group  4  Class  1  equipments  keep  their  original  protocol,  and  they  were 
accommodated.  As  a  result,  the  CCITT  also,  inadvertently,  excluded  Group  4  Class  1 
equipments  from  using  the  newer,  OSI  compliant  protocol  (Both  protocols  should  probably  have 
been  allowed).  Since  then  several  attempts  have  been  made  to  bring  Group  4  Class  1 
equipments  in  line  with  the  revised  DTAM  Recommendations,  and  the  OSI  standards  (See 
Figure  1-1,  change  from  T.62  to  T.62bis,  and  change  from  T.70  to  X.215,  etc.).  Nevertheless, 
Group  4  Class  1  equipments  are  still  unable  to  communicate  with  Group  4  Class  2  or  Class  3 
equipments,  or  vice  versa. 
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In  addition,  Group  4,  regardless  of  the  protocol  stack  used,  adheres  to  the  CCITT’s  Open 
Document  Architecture  (ODA)  concept.  The  ODA  facilitates  the  interchange  of  documents  to 
permit  the  following  items: 

-  different  types  of  content,  including  text,  image,  graphic,  and  sound,  can 
coexist  within  a  document. 

-  the  intentions  of  a  document  originator  with  respect  to  editing,  formatting, 
and  presentation  is  communicated  effectively. 


To  this  end,  ODA  defines  three  forms  of  document  representation: 

Formatted  Form  -  Documents  are  presented  as  intended  by  the 

originator. 

Processable  Form  -  Documents  may  be  edited  and  formatted. 

Formatted  Processable  Form  -  Documents  may  be  presented,  edited,  and 

reformatted. 

Of  these  three,  Group  4  uses  the  formatted  form. 


1.1.2  Encoding  Algorithm 

The  basic  coding  scheme  is  the  same,  in  principle,  as  Group  3’s  two-dimensional  coding 
scheme.  Major  differences  between  the  two  are  1)  Group  4  does  not  use  one-dimensionally 
coded  lines,  and  2)  Group  4  does  not  use  "end  of  line  codes"  except  as  end  of  facsimile 
information  indicators  (i.e.,  they  are  not  present  on  a  line  by  line  basis).  To  jump  start  a 
document’s  facsimile  encoding,  Group  4  places  an  imaginary  white  line  at  the  beginning  of  the 
facsimile  data. 


1.1.3  Transmission  Rate 

Intended  Group  4  transmission  rates  are  56  kb/s  and  64  kb/s  (ISDN).  If  an  8'/^  x  11, 
400  pel  per  inch  document  is  sent  compressed  (say  10:1)  at  64  kb/s,  it  will  take  23.3  seconds 
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for  it  to  arrive  at  its  destination.  If  it  were  a  200  pel  per  inch  document,  it  would  take  5.8 
seconds. 


1.1.4  Planned  Future  Expansion 

The  CCnr  would  like  Class  3  terminals  to  be  able  to  present  documents,  and  permit 
editing  and  reformatting  (Formatted  Processable  form). 

In  addition,  the  CCFTT  would  like  equipments  adhering  to  the  different  classes  to  be  able 
to  interoperate.  Some  administrations  are  considering  a  new  Group  4  Class  1  which  would  be 
able  to  interoperate  with  Classes  2  and  3,  and  which  would  coexist  with  today’s  Group  4 
Class  1. 

Finally,  like  Group  3,  efforts  are  underway  to  simplify  or  peimit  Group  4’s  operation 
in  audiographic  conferencing,  as  well  as  permitting  the  transmission  of  gray  scale  and  color 
documents. 


2.0  GROUP  4  VALIDATION  SYSTEM  OVERVIEW 


The  primary  purpose  of  the  Group  4  Validation  System  (G4VS)  is  to  test  and  evaluate 
Group  4  fecsimile  equipments.  It  verifies  that  Group  4  facsimile  equipments,  the  units  under 
test  (UUTs),  properly  implement  layers  3  through  7  of  the  telematic  protocol  structure  for  Group 
4  facsimile  equipments  and  conform  to  allowable  parameter  variations  within  each  protocol  layer 
(e.g.  buffer  sizes,  timeouts,  etc.).  The  telematic  protocol  structure  adheres  to  the  seven  layer 
Open  Systems  Interconnect  architecture  (OSI).  Testing  of  layers  1  and  2,  the  physical  and  I'nk 
layers,  is  assumed  to  be  done  by  other  means.  Nevertheless,  protocol  violations  or 
unrecoverable  errors  are  reported  to  the  higher  layers.  Originally,  the  G4VS  was  implemented 
with  layers  3  through  7  and  all  necessary  control  routines  using  Delta’s  HP  1000  processor.  At 
present,  it  resides  on  an  IBM  compatible  PC,  and  is  being  vigorously  tested. 

OSI  is  being  evolved  by  the  International  Organization  for  Standardization  (ISO)  whose 
primary  goal  is  to  define  standards  to  allow  different  systems  to  communicate,  with  a  secondary 
goal  of  retaining  existing  standards  whenever  possible. 

OSI  consists  of  a  seven-layer  model  or  framework  which  ensures  that  all  new 
communication  standards  are  compatible.  Secondly,  a  system  obeying  the  OSI  model  in  its 
communication  with  other  systems  is  termed  an  "open  system".  The  OSI  open  systems  concept 
allows  application  processes  to  interact  with  any  other  application  process  anywhere  in  the 
world.  The  seven  layers  of  the  OSI  model  are  divided  among  three  different  functions:  user 
interaction,  interface,  and  communication  network  interaction  (See  Figure  1-2). 


Layer 

Function 

7  Application 

User 

Interaction 

6  Presentation 

5  Session 

4  T  ransport 

Interface 

3  Network 

{ 'iBi'nication 

Net.  rk  I nteract i on 

2  Data  Link 

1  Physical 

PSTN 
ISON 
■>  PSON 
LAN 


Figure  1-2.  The  OSI  Model 


The  seven  layers  have  the  following  definitions: 


Application 

Presentation 

Session 
Transport 
Network 
Data  Link 
Physical 


-  The  highest  level.  It  is  the  user  interface  between  services  and  the 
OSI  environment. 

-  The  presentation  layer  handles  session  establishment  and 
termination  requests,  and  it  preserves  the  meaning  of  data  while 
resolving  syntax  differences. 

-  The  session  layer  establishes,  manages,  and  releases  the 
communication  connection. 

-  Acts  as  a  consistent  interface  between  the  application-related 
functions  and  the  transmission-related  functions. 

-  Provides  routing  and  relaying  through  switched  telecommunication 
media. 

-  Reliably  transfers  all  information  over  the  physical  transmission 
media. 

-  Deals  with  the  transmission  of  a  bit  stream,  regardless  of  its 
meaning,  across  a  physical  communication  medium. 


The  G4VS  consists  of  four  main  parts:  a  system  executive,  a  test  controller,  a  Group  4 
terminal  emulator,  and  a  pseudo  Group  4  UUT.  The  system  executive,  test  controller,  and 
terminal  emulator  are  the  heart  of  the  G4VS.  The  pseudo  Group  4  UUT  (controlled  by  the 
system  executive)  permits  a  thorough  testing  of  the  system  on  a  stand-alone  basis.  For  "live" 
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tests,  a  real  UUT  replaces  the  pseudo  UUT.  The  system  executive  controls  the  execution  of 
selected  tests  and  verifies  that  the  Group  4  UUT  is  operating  correctly.  The  terminal  emulator 
simulates  a  "model"  Group  4  terminal  and  performs  all  operations  as  requested  by  the  system 
executive  and  test  controller. 

Software  for  the  G4VS  was  written  in  Fortran  77  to  maximize  transportability  between 
operating  systems.  Furthermore,  its  design  and  development  used  top-down  structuring 
techniques  which  produced  software  that  is  highly  modular  and  easily  modified.  An  advantage 
when  attempting  to  keep  the  software  aligned  with  evolving  CCITT  Recommendations. 
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3.0  VALIDATION  SYSTEM  DESIGN 


3.1  System  Concept 

Since  the  basis  for  Group  4  Facsimile  equipment  is  the  Telematic  protocols  as 
described  in  the  CCITT  recommendations,  listed  in  Figure  3-1,  the  validation  system  software’s 
primary  responsibility  is  the  implementation  and  validation  of  these  protocols.  Along  with  this 
requirement,  the  validation  system  must  also  be  capable  of  specifying  and  testing  the  different 
parameters/variables  allowed  within  each  of  the  protocol  layers  as  defined  in  the 
recommendation  for  that  layer.  Shown  in  Figure  3-2  is  a  functional  block  diagram  of  the 
validation  system  software.  From  an  overall  point  of  view,  the  validation  system  drives  two  (2) 
operations  -  the  UUT  and  the  G4  terminal  emulator  -  and  compares  the  results.  The  emulator 
acts  as  a  "golden"  model  against  which  the  performance  of  the  UUT  is  compared,  giving  due 
allowance  for  permissible  variations  in  operation.  By  substituting  another  copy  of  the  emulation 
and  its  interface  for  the  UUT,  the  validation  software  itself  can  be  tested,  with  the  help  of  both 
proper  and  selected  improper  variation  controls  applied  to  the  "UUT"  emulation.  In  operation, 
the  system  executive  functions  as  the  user  layer  (a  pseudo  layer  7.5),  along  with  the  operator 
interface  and  the  test  package  data.  An  event  queue  functions  as  the  command  and  data  channel, 
in  both  directions,  between  the  system  executive  and  the  two  validation  instantiations;  the  queue, 
in  effect,  functions  as  the  link  between  the  software  portion  of  the  system  resident  on  the 
validation  processor  and  the  UUT.  The  system  executive  starts  and  stops  processes,  in  response 
to  commands  via  the  operator  interface  and  completion  (successful  or  not)  indications  from  the 
validations,  and  also  examines  the  event  queue  to  determine  which  modules  to  poll  for  action. 
Each  module,  when  polled,  modifies  a  state  (or  substate)  or  moves  data  as  appropriate;  the 
comparator  is  then  called  to  determine  if  the  action  taken  was  permissible,  via  comparison  with 
the  "good"  model,  in  some  cases  forcing  the  latter  to  match  the  actual  UUT’s  (or  in  test  mode, 
the  possibly  faulted  validation’s)  action,  if  a  permissible  variation. 
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Figure  3-1.  CCITT  "Blue  Book*  Recommendation  by  Layer  for  Class  I  Group  4  Facsimile 
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3.1.1  Design  Philosophy 


Thoroughness  of  testing,  and  the  fineness  of  detail  in  the  results  obtained  from  tests,  were 
the  driving  principles  in  the  design  of  the  system.  This  consideration,  reinforced  by  structured 
programming  principles,  dictated  that  all  actions  which  are  significant  (in  protocol  terms)  be 
made  visible  by  small  modules.  In  order  to  make  the  system  capable  of  maintenance  and 
enhancement,  modules  were  aligned  to  the  layering  (in  the  OSI  sense)  and  to  the  CCITT  protocol 
recommendations  which  they  implement.  In  this  way,  the  scope  of  the  system  as  a  whole  can 
be  easily  broadened,  and  modifications  to  the  CCm  protocols  have  been  incorporated  with 
relative  ease.  Fortran  77  was  chosen  as  source  language  for  the  validation  system  because  of 
its  portability,  efficiency,  and  its  structuring  (especially  with  MIL-STD-1753  enhancements). 
Its  support  for  serially  reusable  modules  permits  modules  dedicated  to  protocol  functions  which 
are  usable  by  both  the  UUT  and  the  emulation  subsystems,  on  both  sides  of  the  interface.  The 
use  of  reusable  modules  are  strongly  advised  by  redundancy  and  inconsistency  considerations. 
Fortran’s  COMMON  blocks  are  used  to  store  states,  substates,  and  overall  status.  The  event 
queue  is  used  not  only  as  a  "mailbox”  between  modules  for  interlevel  commands,  but  also  as  a 
journal  for  the  actions  taken  by  the  UUT  and  emulations  of  it.  With  the  use  of  multiple  linked 
lists,  each  corresponding  to  a  specific  event,  maintained  by  well  tried  "heap"  storage 
management  techniques,  each  module  quickly  performs  its  intended  function.  In  coding  the 
various  modules,  strict  adherence  to  ANSI  X3.9-1978  extended  by  MIL-STD-1753,  both  in  letter 
and  spirit,  was  followed.  This  policy  not  only  guarantees  relative  ease  in  porting  software  from 
processor  to  processor  but  also  guarantees  the  reusability  of  modules  as  mentioned  above. 
Module  reentrancy  was  not  relied  upon,  but  has  been  taken  advantage  of  (usually  by 
multitasking)  where  available. 


3.1.2  Design  Approach 

A  top-down  methodology  was  followed  in  the  software  design  of  the  system.  The  system 
itself  was  structured  as  "open-ended",  using  small  modules.  Each  module  when  coded  was 
essentially  complete,  but  those  of  its  functions  which  were  not  needed  in  the  present  description 
of  the  system  resulted  in  direct  or  indirect  invocations  of  "stubs"  or  placeholder  modules.  When 
it  is  necessary  to  add  a  given  function  to  the  system,  the  modules  completing  that  function  can 
be  substituted  for  the  stubs.  The  event  queue  approach  was  chosen  to  bring  as  many  protocol 
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actions  as  feasible  out  into  the  open,  where  the  performance  of  the  UUT  can  be  compared  in 
detail  with  a  properly  acting  model  supposedly  compatible  with  it.  It  permits  detailed  error 
reports  which  not  only  back  up  invalidity  decisions  but  also  aid  the  agency  requesting  the 
validation,  without  the  use  of  difficult-to-implement  protocol  conformance  evaluations  in  the 
large.  The  approach  also  enhanced  the  open-endedness  of  the  system,  particularly  with  regard 
to  added  functionality  and  CCITT  recommendation  revisions.  Other  service  routines  were 
specified  and  implemented  as  the  need  for  them  became  apparent. 


3.2  Validation  System  Description 

From  a  functional  point  of  view,  the  validation  system  is  comprised  of  the  following 

parts: 


Operator  Interface 
Test  Package 
System  Executive 

UUT  Subsystem  and  status/buffer  stores 
Emulator  Subsystem  and  status/buffer  stores 
UUT/Emulator  Comparator 
Event  queue  and  allied  management  software 

The  following  details  the  part  played  in  the  operation  by  each  of  these  subsystems. 


3.2.1  Operator  Interface 

This  set  of  modules  provides  the  means  by  which  specific  tests  can  be  selected  and 
initiated,  and  the  results  of  tests  returned,  in  the  form  and  in  detail  requested  by  the  operator. 
It  also  provides  the  operator  step-by-step  instructions  for  normal  UUT  validations,  including 
selection  of  alternate  protocols  where  appropriate.  For  maintenance  and  diagnostic  purposes, 
the  operator  may  also  choose  between  parallel  and  serial  UUT  and  emulation  operation,  and  may 
also  compare  a  selectively  faulted  emulation  with  an  unfeulted  model.  Internal  to  the  system,  this 
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subsystem  maintains  a  table  of  testing  options,  and  calls  the  system  executive  to  start,  resume, 
or  wrap  up  a  test  as  instructed. 


3.2.2  Test  Package 

While  no  modules  are  strictly  part  of  the  test  package,  this  must  be  considered  part  of 
the  system  as  a  whole.  This  package  will  normally  reside  on  auxiliary  storage,  and  can  be  easily 
substituted  for  special  purposes.  Basically,  it  consists  of  test  data  for  transmission,  plus  control 
information  for  selecting  modes  of  operation  on  various  levels.  These  modes  include  not  only 
permissible  alternatives  but  also  invalid  ones  to  test  the  UUT’s  capability  to  react  properly  to 
protocol  errors. 


3.2.3  System  Executive 

When  invoked  by  the  operator  interface,  the  system  executive  initiates  the  selected  task 
by  obtaining  testing  information  from  the  test  package,  storing  it  and  initializing  the  event  queue 
as  appropriate.  Thereafter,  it  polls  the  linked  lists  which  make  up  the  event  queue  and  calls  the 
appropriate  modules  to  take  action.  On  test  completion  or  an  abort  condition  signaled  by  the 
comparator  subsystem,  the  general  nature  of  the  test  result  is  passed  to  the  operator  interface, 
so  that  detailed  test  result  data  can  be  printed  or  otherwise  provided.  Executive  polling  can  be 
done  in  two  ways,  roughly  describable  as  parallel  and  serial.  In  the  parallel  mode,  the  UUT  and 
the  emulation  are  kept  essentially  in  step  with  one  another;  the  UUT  is  blocked  from  getting 
more  than  a  single  significant  protocol  event  ahead  of  the  emulation.  In  this  mode,  the  UUT 
does  not  proceed  to  step  N+ 1  until  the  emulator  has  taken  step  N  and  its  action  compared  with 
the  corresponding  UUT  step.  This  mode  is  particularly  useful  for  detailed  examination  of 
operation,  especially  in  debugging.  The  serial  mode,  on  the  other  hand,  allows  UUT  actions 
to  have  priority  over  emulation  actions,  letting  the  UUT  "run  free",  so  to  speak.  The  emulator, 
and  the  comparison  of  its  actions  with  the  UUT,  are  handled  as  time  is  available,  using  the  event 
queue  as  the  UUT  "history"  medium.  Serial  mode  may  be  required  for  some  terminals  and 
modes  of  operation;  for  emulation-to-emulation  comparisons,  the  parallel  mode  is  obviously 
preferable. 
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3.2.4  UUT  Subsystem 


This  subsystem  consists  of  a  set  of  modules,  shared  with  the  emulator  subsystem,  which 
implement  the  protocols  and  functions  called  for  at  each  layer  of  the  OSI  model.  What  actually 
dedicates  it  to  the  UUT  (or  an  emulation  of  one)  is  the  functional  incorporation  of  the  UUT  and 
its  hardware  interface  into  the  system,  and  the  stored  status,  buffers,  and  linked  lists  specifically 
associated  to  the  UUT  or  its  standin.  The  procedure  modules,  as  such,  function  as  routines 
dedicated  to  their  protocol  implementation  and  transmission  functions,  rather  than  that  of 
interfacing  to  the  UUT  or  providing  a  control  against  which  the  UUT  performance  can  be 
evaluated. 

Each  module  performs  one  or  more  actions  corresponding  either  to  protocol-specified 
change  of  state  or  substate,  or  performs  inter-layer  translation  functions.  A  module  is  thereby 
identified  with  specific  sections  or  subsections  of  the  protocol  recommendation  which  it 
implements;  its  actions,  rather  that  being  "hard-coded",  are  driven  by  a  decision  table  closely 
reflecting  the  "state  diagrams"  included  with  some  of  the  CCITT  protocol  recommendations, 
even  to  the  state  numbers  and  other  annotation.  When  unavailable,  the  decision  tables  reflect 
the  intended  purposes  of  the  associated  recommendations.  The  decision  tables,  fixed  at  compile 
time,  are  supplemented  by  parallel  mask  and  vector  tables  which  can  modify  actions  either  to 
reflect  alternative  actions  or  transmission  paths,  or  to  force  improper  actions  to  be  taken,  either 
to  test  the  UUT’s  reaction  to  them,  or  for  debugging  purposes,  especially  in  emulation  vs 
emulation  tests.  These  supplementary  tables  are  modified  during  execution  to  implement 
alternate  protocol  choices,  hardware  vs  software  module  implementations,  and  "error-force" 
option  selections. 

The  heart  of  the  UUT  subsystem,  as  such,  is  the  stored  data  which  reflects  the  current 
states  and  substates  of  the  UUT  transmission  in  progress,  the  linked  lists  containing,  by  layer 
and  direction,  the  history  of  the  transmission,  and  the  transmitted  data  itself.  Substates,  as  far 
as  the  software  is  concerned,  simply  provide  a  more  detailed  description  that  the  CCITT-defined 
states  as  such;  the  designation  was  chosen  to  keep  the  coarser  states  in  line  with  the  CCITT 
specifications.  Relative  to  states,  substates  record  such  details  as  timeout  counts,  intermediate 
status  in  combine/divide  operations,  and  other  data  needed  to  define  fully  the  status  of  a  given 
transmission. 
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The  linked  lists  provide  the  main  mechanism  by  which  the  protocol  modules  communicate 
with  one  another.  In  operation,  the  executive  polls  all  linked  lists  for  unhandled  events;  when 
one  is  found,  the  appropriate  protocol  module  "handles”  the  event,  usually  marks  it  as  "done" 
and  places  another  event  on  another  linked  list  for  some  other  module  to  handle,  modifying  the 
stored  status  accordingly.  In  cases  where  the  correspondence  between  "input"  and  "output" 
events  is  not  one-to-one,  the  module  may  delay  "signing  off"  on  the  input  event  or  placing 
another  event  on  its  own  input  linked  list  as  is  appropriate,  to  guarantee  that  is  be  polled  to 
complete  its  function.  In  any  case,  the  action  taken  by  a  protocol  module  on  one  invocation  is 
scaled  down  to  a  maximum  of  one  event  in  or  out. 


3.2.5  Emulator  Subsystem 

The  emulator  subsystem  shares  all  its  protocol  procedure  modules  (except  where  replaced 
by  hardware/firmware  links)  with  the  UUT  subsystem;  the  difference  is  in  the  status  and  buffer 
stores  dedicated  to  the  subsystem,  the  linked  lists  which  provide  layer  interfaces,  and  the  method 
by  which  supervisory  control  over  it  is  exercised.  Each  protocol  module  is  ignorant  whether  it 
is  performing  its  function  for  the  UUT  emulator,  but  is  provided  with  the  status  tables,  linked 
lists,  etc.,  peculiar  to  one  or  the  other  by  the  calling  executive.  The  basic  decision  tables  used 
are  the  same  as  for  the  UUT,  but  supplementary  mask  and  vector  tables  may  differ,  according 
to  the  purpose  of  particular  tests,  and  the  double  use  of  emulator  modules  on  both  the  DTE  and 
DCE  sides  of  the  transmission,  for  example  when  the  effect  of  one  sided  protocol  errors  are 
being  tested.  The  difference  in  supervisory  control  is  implemented  by  the  comparator 
subsystem,  working  with  the  executive,  as  described  below. 


3.2.6  UUT/Emulator  Comparator 

The  job  of  the  comparator  subsystem  is  to  keep  the  UUT  and  emulator  systems  in  line 
with  another,  comparing  their  actions  on  an  event  by  event  basis,  and  reporting  on  serious 
discrepancies.  In  order  to  do  this,  actions  taken  by  protocol  modules  on  both  sides  are  "filtered" 
through  a  comparator  module  which  takes  differential  actions,  depending  on  the  "side"  from 
which  the  action  emanates.  On  the  UUT  side,  in  serial  mode  actions  are  allowed  to  proceed; 
in  parallel  mode,  an  action  may  be  held  up  until  the  emulator  side  has  reacted  to  the 
corresponding  stimulus.  This  is  accomplished  by  the  protocol  module  placing  its  generated 
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events  on  the  comparator  module’s  stimulus  list;  the  comparator  will  pass  it  on  (by  relinking) 
when  and  if  appropriate.  Once  both  sides  have  reacted  to  corresponding  stimuli,  results  are 
compared.  If  they  match,  the  process  is  allowed  to  continue  with  no  special  action  being  taken. 
If  the  action  taken  by  the  UUT  side  is  a  valid  alternative  to  that  of  the  emulator,  the  latter’s 
action  is  modified  to  match  the  UUT.  Otherwise,  an  error  report  is  generated  and  the  entire 
process  is  aborted  or  modified  and  force  to  continue  as  is  appropriate  to  the  seriousness  of  the 
error  and  pertinent  operational  modes  as  set  by  the  operator. 

In  cases  where  only  one  side  is  a  software  module  whose  stimuli  and  responses  are 
available  to  the  comparator  (for  example,  the  DTE-end  emulator  paralleled  to  the  UUT  itselO, 
no  attempt  is  made  to  keep  actions  in  line.  Instead,  the  "small"  actions  on  the  "soft"  side  are 
assumed  to  match  the  other  side,  and  alignment  and  comparison  are  deferred  to  a  layer  where 
both  sides  are  available.  No  error  reports  are  generated  where  mismatches  can  not  be 
diagnosed,  of  course;  however,  the  comparator  subsystem,  through  suitable  interface  modules, 
will  merge  error  detections  passed  on  by  hardware/firmware  modules  into  the  same  eiror  report 
list  used  by  software/software  mismatch  reports. 

3.2.7  Event  Queue  and  Associated  Management  Facilities 

Although  each  event  "belongs"  to  a  specific  side,  layer,  and  module  at  any  given  time, 
its  structure  is  common  to  the  overall  process  itself.  Storage  for  each  event  is  allocated  in  space 
available  to  all  modules,  via  common  allocation/garbage  collection  routines.  For  auditing 
purposes,  all  events  are  linked  by  time  of  generation;  for  functional  purposes,  a  second  linkage 
is  used  to  connect  them  with  previous  and  successive  events  at  the  same  and  neighboring  layers. 
This  latter  connection  is  modified  (by  relinking)  by  comparator  modules  in  order  to  let  a  process 
continue  or  to  "roll  back"  a  given  action. 

Each  event  contains,  at  a  minimum,  the  following  information: 

(1)  An  indication  of  the  nature  of  the  event,  including  codes  for  layers  involved; 

(2)  An  indication  of  the  "side"  (UUT  vs.  emulation),  "end"  (DCE  vs.  DTE),  and 
direction  of  the  event; 

(3)  Clock  time  for  the  event; 
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(4)  List  linkages  (on  time  and  functional  bases); 

(5)  Linkages  to  data,  where  appropriate; 

(6)  Indications  of  state  changes  associated  with  the  event. 

Associated  with  the  event  queue  is  not  only  the  allocation  routines  mentioned  above,  but 
also  other  service  routines  performing  such  tasks  as  relinking  lists  and  similar  functions.  A  real 
time  clock  of  adequate  precision  is  used  to  provide  event  timing  for  timeout  sequences  and 
similar  functions.  Similarly,  for  reporting  purposes,  routines  are  required  for  editing  compact 
error  reports  from  the  comparator  subsystem  into  terms  the  operator  can  recognize. 
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4.0  ccnr  GROUP  4  RECOMMENDATION  REVISIONS 


Recent  revisions  to  the  CCi  ri  Recommendations  concerning  Group  4  facsimile  include 
North  American  legal  and  North  American  ledger  document  sizes,  definition  of  bit  ordering,  and 
the  interfacing  of  Group  4  to  ISDN.  Of  these  only  page  formats  have  been  approved,  and 
approval  for  the  recommendation  for  interfacing  Group  4  to  ISDN  (T.90)  is  being  sought  under 
resolution  2  procedures.  Work  has  also  begun  on  gray  scale  and  color. 


4.1  ISDN 

ISDN  has  its  roots  in  the  development  of  digital  telephone  networks,  and  whose  purpose 
is  to  provide  end-to-end  digital  connections  to  support  a  wide  range  of  telecommunication 
services  (including  fax).  ISDN  provides  users  with  two  64  kb/s  (B)  channels  for  data 
independent  of  signalling,  and  one  16  kb/s  (D)  channel  of  which  10  kb/s  may  be  available  for 
Packet  Switched  Communication.  The  two  B  channels  make  it  possible  to  conduct  two 
simultaneous,  and  unrelated,  communications.  Moreover,  additional  packet-switched  information 
can  flow  over  the  D  channel,  if  the  local  exchange  is  equipped  to  handle  it.  Normally,  the  D 
channel  is  used  for  call  control,  keeping  the  B  channels  completely  free  for  information 
transport.  The  ISDN  allows  the  telephone  companies  to  provide  users  with  three  types  of 
connection  capabilities:  circuit- switched  (telephony),  packet-switched  (data  communication 
applications),  and  permanent  circuits  for  private  network  applications. 

The  maturing  T.90  Recommendation  defines  how  telematic  equipments  may  use  ISDN. 
Recent  proposed  modifications  include  defining  synchronization,  procedures  for  B-channel 
negotiation  of  layer  2  parameters,  and  how  facsimile  terminals  interwork  on  ISDN. 

Within  ISDN  there  is  no  end-to-end  signalling  concerning  activation  of  the  protocol 
instances.  To  ensure  an  instance  of  the  data  link  protocol  only  sends  its  first  frame  when  the 
peer  entity  is  ready  to  receive  it,  a  proposed  synchronization  modification  recommends  sending 
"1"  bits  over  the  B  chennel  until  the  B  channel  is  connected.  (See  Figure  4-1.)  Procedures  for 
B-channel  negotiation  of  layer  2  parameters  defines  the  Exchange  Identification  (XID)  Frame 
for  exchange  of  layer  2  parameters  (i.e.,  modulo  and  k  parameter).  The  XID  is  an  element  of 
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Figure  4-1.  Synchronization  Sequence  on  Layer  2 


the  ISO-standardized  High-Level  Data  Link  Control  procedures  (HDLC),  as  realized  in  CCITT 
Recommendations  Q.920/Q.921  (LAPD). 

The  interworking  of  facsimile  terminals  on  ISDN  recommends  that,  in  general,  Group 
2  and  Group  3  equipments  should  use  a  3.1  kHz  audio  bearer  capability.  Group  4  may  use 
either  "circuit-mode  64  kb/s  unrestricted  8  kHz  structured"  or  "virtual  call"  or  both. 
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4.2  Gray  Scale  and  Color  Documents 


A  color  Group  4  expert  group  under  Question  4  of  Study  Group  VIII  is  working  on 
producing  a  first  draft  of  a  Group  4  color  facsimile  Recommendation  for  the  CdTT.P^  They 
are  evaluating  issues  like  coding  algorithms  and  color  spaces  with  respect  to  certain  performance 
objectives.  Possible  performance  objectives  are  continuous-tone  color  images,  64  Kb/s 
transmission  rates,  and  transmission  of  an  A4  page  in  one  minute  or  less  at  200  pixels/inch.  A 
number  of  color  spaces  are  being  considered.  In  general,  except  for  high-end  applications  that 
require  very  high  quality  printing  and  where  a  specific  color  space  (e.g.,  CMY(K))  is  needed, 
luminance-chrominance  spaces  are  considered  as  the  most  appropriate  for  other  applications, 
with  YCbCr  and  CIBLAB  being  the  best  candidates.  YCbCr  is  well  known  and  widespread  and 
is  consistent  with  videotelephony,  and  videotex;  however,  it  is  ill-defined,  is  dependent  on  the 
gamma  properties  of  display  screens,  and  may  have  conversion  problems  with  other  color 
spaces.  CIELAB  is  a  uniform  space,  is  a  more  accurate  representation  of  color,  and  is 
supported  by  ISO  and  ODA;  but  it  is  less  widespread  and  is  incompatible  with  some 
applications. 

The  Joint  Photographic  Experts  Group  (JPEG)  and  the  Joint  Bi-Level  Experts  Group 
(JBIG)  coding  techniques  are  under  consideration  for  the  coding  algorithm;  but  should  be 
considered  as  independent  options.  In  general,  JPEG  has  lossy  and  lossless  modes  with  the 
baseline  system  being  lossy.  JBIG  is  only  lossless  and  permits  coding  of  color  documents  by 
coding  bitplanes.  A  comparison  of  JBIG  and  JPEG  (in  lossless  mode  with  arithmetic  coding) 
shows  the  best  performance  with  JBIG  for  documents  with  less  than  8  bits/pixel.  So  JBIG  could 
be  an  alternative  to  JPEG  for  lossless  coding.  For  continuous-tone  and  lossy  coding,  JPEG 
appears  to  be  more  appropriate. 


4.3  Tiling 

Although  there  has  been  no  formal  work  in  CCITT  Study  Group  VIII  regarding  tiling  in 
Group  4  facsimile,  some  have  expressed  interest  in  adding  this  capability  in  the  future.  Tiling 


4  -  3 


Nuabar  of  polo  par  llna 


Nuabar  of  polo 
par  tila  llna 


PEL  ABSAY 


CONTENT 

PORTION 


Figure  4-2.  Tiles  and  Pel  Arrays 


segments  a  pel  array  into  a  two  dimensional  array  of  non¬ 
overlapping  rectangular  regions  called  tiles.  (See  Figure  4-2 
and  Figure  4-3.)  Tiling  permits  the  independent  coding  of 
the  content  information  of  each  tile.  Second,  tiling  makes 
it  easier  to  access  or  process  portions  of  the  pel  array 
independent  of  the  remaining  portions.  Each  tile  is 
encodable  using  T.4,  T.6,  or  bitmap  encoding.  The  default 
is  T.6.  If  the  pels  within  a  tile  are  either  all  foreground  or 
all  background,  the  tile  may  be  omitted.  The  capability  to 
encode  each  tile  separately  as  bitmap,  compressed  or  null 
maximizes  the  possible  compression  to  the  tiled  pel  array. 
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5.0  SUMMARY  AND  AREAS  OF  FUTURE  STUDY 


The  Group  4  Validation  System  has  been  installed  on  two  systems:  the  HP  1000  and  an 
IBM  PC  compatible.  Both  support  layers  3  and  up,  and  on  the  HP  1000,  hardware  is  provided 
for  layers  1  and  2.  At  present.  Delta  is  testing  the  IBM  PC  compatible  version. 

With  the  exception  of  items  like  some  new  page  formats  (e.g..  North  American  legal), 
most  Recommendation  efforts  concerning  Group  4  facsimile  are  still  changing.  Color  and  gray 
scale  recommendations  concerning  Group  4  fax  are  in  early  stages  of  development  and  are  likely 
to  change  as  they  mature.  The  proposed  Recommendation  for  interfacing  Group  4  to  ISDN 
(T.90)  has  just  recently  been  agreed  upon  and  approval  is  now  being  sought  using  resolution  2 
procedures.  For  Recommendations  that  are  stable  (e.g.,  page  formats)  or  proposed  revisions 
with  possibly  low  risk,  the  Group  4  Validation  System  was  modified  to  accurately  reflect  those 
recommendations. 

Future  modifications  to  the  Group  4  Validation  System  could  include  a  ISDN  interface 
(once  T.90  is  approved),  and  could  include  color  and  gray  scale  imagery  as  recommendations 
concerning  them  get  closer  to  approval. 

This  report  has  presented  a  general  overview  of  the  Group  4  Validation  System.  For  the 
complete  history  of  the  Group  4  Validation  System  and  detailed  information  concerning  its 
development,  please  refer  to  the  following  reports:^^’’^*'  '®’ 

"Development  of  a  Validation  System  for  Group  4  Facsimile  Equipment,"  1985 

"Modification  of  Group  4  Validation  System,"  1989 

"Modification  of  the  Group  4  ValidatUm  System,"  1990 
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